A while ago I enabled auditing on my WS2008 Servers and started noticing the following event repeating in the Securtiy log.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 12/14/2008 7:10:02 PM
Event ID: 4674
Task Category: Sensitive Privilege Use
Level: Information
Keywords: Audit Failure
User: N/A
Computer: <Computer FQDN Here>
Description:
An operation was attempted on a privileged object.

Subject:
Security ID:LOCAL SERVICE
Account Name:LOCAL SERVICE
Account Domain:NT AUTHORITY
Logon ID:0x3e5

Object:
Object Server:Security
Object Type:-
Object Name:-
Object Handle:0x0

Process Information:
Process ID:0x294
Process Name:C:\Windows\System32\lsass.exe

Requested Operation:
Desired Access:16777216
Privileges:SeSecurityPrivilege

I found no public description of what it means and what I am supposed to do. It seemed to me that something cannot execute because'LOCAL SERVICE' needs 'SeSecurityPrivilege' (aka 'Manage auditing and security log') right. Okay, I granted this right (double checked with RSoP and Local Policy Editor) but nothing changed. I even tried to grant this rigth to 'System' account also (by default only 'Administrators' have it). But this didn't help either.

So my question is: what should I do to get rid of these events (other then disabling auditing)? Thanks in advance.


P.S. A few links Itried but that didn'tadd to my understanding.

• Events and Errors Message Center Search nothing at all.
• EventID Search nothnig at all.
• Randy Franklin Smith's UltimateWindowsSecurity.comWiki article on SeSecurityPrivilege interesting, but nothing particularly helpful for this special case.
• Randy Franklin Smith's UltimateWindowsSecurity.comWiki article onEvent 4674 nearly meaningless.

And that's all at least slightly relevant information I could find.

This looks like you are trying to make a (very) secure server. To 'get rid' of these events you'd only have to change the properties of the event log so that it will not report 'failed security audits'. A server based on object access rather then user permissions has its (inherent) drawbacks. The former is not designed for public access.

Bump!

Sorry, but the proposed answer is not an answer at all!

My initial answer on the matter seems to correct after all, in the strict sense of the word. My background information was completely wrong. I've been meaning to correct this since I've seen the reply by MVP Pronichkin . The event is described as Privileged use, subcategory Sensitive privileges exercised by User rights/Privileges (interchangeable/synonymous) OR An operation was attempted on a privileged object.
But the type is typically set to display a succesful audit. Nevertheless, by the actions you've taken you've eliminated all other, except for the fact that ms admits overloading these privileges so that each privilege can access (or even govern, according to some sources) the authority to perform many different operations. The priveliges required for exercising an operation are just not there or the information is partial and cannot be trusted. So the fact that a privelidge was accessed is meaningless. Microsoft is aware of the problem and the fact that is a high level event. "Still you can't act upon it since they do not describe the event." It's considered 'noise'. The corresponding event in windows 2003 is 578 and just as vague: Privileges were used on an already open handle to a protected object. These two event descriptions support the consideration of 'noise', evnt 578 even confirms it. Multiple instances of the privileges being used at the same time. I've seen event 578 in combination with either 560 and 565 many times; meaning Access was granted to an already existing object and Access was granted to an already existing object type. Now that I've typed it all I see it's probably just overrated network traffic. Server 2008 has much better logging capabilities, wouldn't surprise me a little patch would solve this issue.

I hope this answers your question. Shems.

>BUMP<

I'm not satisfied with my response. It still bothers me there's little explanation.

Maybe some-one can explain.

So... After a year of complete silence... Anybody!?

I got a pretty good idea what it is...

I wonder if you know some more. This is the only post that kept my attention going .... 

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-4674

Still very confusing ... 

http://technet.microsoft.com/en-us/library/dd772724(WS.10).aspx

So versatile and convenient !

<BUMP>

 

it's worth it.

any news on this one? we can reproduce this event with gpupdate /force

Run this:

auditpol /set /subcategory:"Handle Manipulation" /failure:disable

then, Run Away... :)

Hi

I am experiencing similar symptoms, and even though I have not yet completely resolved my issue, here's what I can say.

In one of my installations (I have two, at least), there is an active directory domain ADOM1 that is integrated into an identity management solution via LDAP/S.

A special user account has been created in the ADOM1. This account has been made a member of BUILTIN\Account Operators group. It's purpose is to allow ID management to bind to one of DCs via LDAP/SSL and manage (update attributes and password) of some user accounts in a dedicated OU.

As some users complained, their passwords are not synchronized to the external source by the identity management solution.

Upon checking, I have found errors 4674 absolutely identical to the topic start.

I have analyzed the difference in "good" and "bad" accounts and "bad" accounts are all members (indirectly) of BUILTIN\Administrators.

According to http://technet.microsoft.com/en-us/library/cc722456.aspx

 "Account Operators can't manage the Administrator user account, the user accounts of administrators, or the group accounts Administrators, Server Operators, Account Operators, Backup Operators, and Print Operators."

So the "privileged object" is simply a VIP account of someone with privileges higher than the managing Account Operator member. Like my own.

And the LSASS.EXE there is simply an impersonation level becase LDAP is used on the external access point. So yes, LSASS takes on "Account Operator" power but then it cannot "chew" tough guys like Administrators. Surely that would've not been right if it did, from security perspective.  Microsoft just removes "smoke and mirror" so that you're not just happy with your wishful thinking that Account Ops stay Account Ops.

This is a design decision, to avoid privilege escalation. Some things are hardcoded in Windows after all...

Hence my conclusion is that the special account for the external identity manager must have Domain Admin privilege! Damn, I wish they have initially agreed to my suggestion to use Domain Trusts!..

The big "WHY" is why same account works in my other installation, having identical memberships and policies?.. Could this be level of patches, windows updates?

This I am still investigating.

• Edited by Sergey Zak Tuesday, November 13, 2012 10:29 AM

I am having the same issue.  Have you ever found the solution?

Thank you,

I am having the same issue too.  Since 2008 until today nobody has found a solution?

security: failure - 2014/06/10 16:56:54 - Microsoft-Windows-Security-Auditing (4674) - n/a
 "An operation was attempted on a privileged object. Subject: Security ID: S-1-5-19
 Account Name: LOCAL SERVICE Account Domain: NT AUTHORITY Logon ID: 0x3e5 Object:
 Object Server: LSA Object Type: - Object Name: - Object Handle: 0x0 Process
 Information: Process ID: 0x1cc Process Name: C:\Windows\System32\lsass.exe Requested
 Operation: Desired Access: 16777216 Privileges: SeSecurityPrivilege"

• Edited by MarceloGuedes Friday, June 13, 2014 1:53 PM Update the information

Update!

Ok, it's sad but i gave up, no solution and anyone to help.

So I have this problem too.  How inept is MSFT?  Why would I purchase any of there future products when they have left items like this unattended for, let's see 

SIX AND A HALF YEARS!!!!!!!!

MSFT is lame and I will not be riding their wagon anymore in the future.

Pronichkin

Bump! Bump! Bump!

When you created the topic, possibly you or was part of the MFST. Now you are a part, hoped that at least answered your own topic, which had the same doubts and should have the same feeling of everyone here, as I could see, no response to all this time. If you think about it, how ironic this situation. Even if it is to report that there is no solution of the problem. We await your response or position.

Still no answer?  It is 2015 and I get these errors in Server 2012 R2.